Joshua Wright talks to NPR about “Free Public WiFi” vulnerability

Joshua Wright talks briefly about the “Free Public WiFi”, adhoc network. This tactic has been around for a longtime. In fact, frequent travelers should be on the look out for hotel chain SSIDs in adhoc mode as well.

Depending on your configuration your wireless supplicant may connect automatically to these adhoc networks without you really knowing. Other times, the users sees a pop up “Free Public WiFi” and willingly connects to the network in hopes of free internet access. To the untrained eye these are wireless networks promising a free WiFi connection. However, you have no idea who is on the other end. The mobile user suspects it a real access point.

This NPR article stops by saying “it’s a bad thing and you should never connect”. But lets cover the why and the how. Suppose  I configure an adhoc wireless network  broadcasting the SSID “Free Public WiFi” from my laptop in a busy area where mobile users frequent. This could be at the mall, airport and conference center for example. The adhoc configuration is simple, so simple in fact it can be done in under a minute. You may recall a number of months ago the Russian spy’s were using adhoc wireless to communicate amongst themselves.   

After I configure my adhoc wireless network. A non suspecting mobile user connects to me thinking they are getting FREE PUBLIC WiFi. But what they don’t realize they are connecting to my laptop. At which point I now have a layer 2 adjacency with this user. From here I could run a DHCP server on a VM local to my laptop. Whereby bridging layer 3 connectivity between me and the unsuspecting mobile user.

Once this is complete it’s a simple launch of Backtrack, whereby I could act as a man in the middle or deploy a library of attacks. 

http://www.npr.org/templates/story/story.php?storyId=130451369 

Wikipedia - http://en.wikipedia.org/wiki/Wireless_security
Security Tube - http://www.securitytube.net/Attacks-on-WiFi-(ADHOC-Networks)-video.aspx
Hot Spots Attacks - http://www.ethicalhacker.net/content/view/66/24/

Cisco WiSM Config Practice Opens SVI Vulnerability

Cisco’s recommend WiSM configuration practice will make you vulnerable – by George Stefanick

I was asked, “The WiSM Config Practice has been out for years, how did you find this ?” The devil is in the details.... 

WiSM Configuration Practice

The initial steps in configuring a Cisco WiSM is what I like to call a “configure-and-forget” step. This is because once the WiSM is configured and married to the backplane of the Sup720 via the “service port” its rare one would need to revisit this procedure again.

There are a number of Cisco WiSM Configuration guides available at cisco.com explaining this process. We will get into these in a bit… 

What is the WiSM “service port”?

First lets understand what the service port interface is and the purpose of the service port. The WiSM service port is one of many ports on a Cisco WiSM. They include the management, ap manager, virtual, service and the operator dynamic interfaces.

•  Management interface (pre-defined and mandatory)
•  AP-Manager interface (pre-defined and mandatory)
•  Virtual interface (pre-defined and mandatory)
•  Service-port interface (pre-defined and mandatory)
•  Operator-defined interface (user-defined)

Cisco’s 4400 and 5500 model controller’s service port is used for out-of-bandwidth management. The service port is a physical port supported on these models, whereby allowing you physical access with a console / null modem cable.

Contrary to the service port on the 4400 and  5500’s models. The WiSM service port is NOT used for out-of-bandwidth management. Rather it is used to synchronize the supervisor engine (720) and the WiSM. 

How does the “service port” on the Cisco WiSM connect to the Sup720?

Once the WiSM is installed, you enter the Sup720 and create a local vlan for the purpose of communications between both the WiSM and the Sup720.  Cisco references vlan 192 in their WiSM config documents, but of course any vlan number can be used. 

Cisco’s WiSM Configuration documentation goes a step further and states to create an SVI interface. An SVI interface is a gateway to bridge traffic. (Here in lies the problem. I will cover in more detail in the next section.)

(See below reference and links to Cisco WiSM configuration Guides, note the SVI interface recommendations and the lack of an ACL) 

The Vulnerability

The Cisco WiSM Configuration Guides detail the creation of an SVI interface for the purpose of the service port interface. For example;

Sup720(config)# interface Vlan 192
Sup720(config-if)# ip address 192.168.10.1 255.255.255.0
Sup720(config-if)# no shutdown
Sup720(config-if)# exit

The Cisco WiSM Guides makes no reference to an ACL which would restrict traffic access to the service port SVI interface. By creating the SVI interface you have a “connected route” from users who terminate to the 6500 to reach the SVI interface. This would include wired and wireless users. Essentially, inside users have access to the WiSM service port. This would also include wireless guest!

Lets follow the packet:

1)     Wireless client pings 192.168.10.1

2)     The packet egresses the wireless client and 802.11 headers are applied

3)     The packet travels via RF

4)     Packet reaches Access Point

5)     Access points encapsulates the packet in a LWAPP/CAPWAP headers

6)     The packet is then sent to the Cisco WiSM / Controller

7)     The WiSM removes the LWAPP/CAPWAP encapsulation and adds 802.3 headers

8)     The WiSM places the packet on the wired

9)     The packet transverses the router to the connected 192.168.10.1 SVI interface

I’m positive this is an oversight by Cisco. Recent conversations with Cisco SE’s, Cisco TAC and other peers agree this is an issue on many levels.

Engineers and Admins who configure the WiSM for the first time or perhaps engineers who have little knowledge would follow the Cisco WiSM Configuration Guide step by step. Not understanding that an ACL needs to be applied to the SVI interface for the WiSM service port. 

Real World Examples:

Lets cover why this is an issue with some real world examples:

Example#1 –

Your inside networks are 10.x.x.x and 172.x.x.x. Your service port on the WiSM is configured for 192.168.10.x network. Users who terminated to the cat / Sup 720 that houses the WiSM has access to the SVI interface 192.168.10.x. Why, because it is a connected route. The traffic will bridge over from 10 / 172  to the 192 network.

Example#2 –

Suppose you don’t have a Cisco WLC to anchor guest traffic. Your wireless guest traffic terminates to the  cat / Sup720 that houses the WiSM. Let suppose you ACL your "GUEST" SVI interface denying your known inside networks. You think you are done and call it a day.

DENY 10.0.0.0 (inside network)

But did you remember to deny 192.168.10.x? If you didn’t your wireless guest now have access to your service port

How to Fix it:

If you configured an SVI interface. Simply ACL the SVI not to allow ANY network access to this SVI interface.  

Conclusion:

I admit this isn’t a five-alarm hole. You don’t have to drop everything you are doing.  But it is one that needs to be addressed if you followed Cisco WiSM Configuration Guides.

Cisco links to WiSM Config

http://www.cisco.com/en/US/docs/wireless/technology/wism/technical/reference/appnote.html

! - Create a vlan in the Supervisor 720, this vlan is local to the chassis and is used for

communication between Cisco WiSM and Catalyst Supervisor 720 over a Gigabit interface on

the Supervisor and service-port in the Cisco WiSM. 

Sup720(config)# vlan 192 

! -- Assign an appropriate IP address and subnet mask for VLAN 192 

Sup720(config)# interface Vlan 192

Sup720(config-if)# ip address 192.168.10.1 255.255.255.0

Sup720(config-if)# no shutdown

Sup720(config-if)# exit

http://www.cisco.com/en/US/products/hw/modules/ps2706/products_tech_note09186a00808330a9.shtml

Create the WiSM Service Port Gateway and assign the IP address.

Create a VLAN in the Supervisor 720. This VLAN is local to the chassis and is used for communication between Cisco WiSM and Catalyst Supervisor 720 over a Gigabit Interface on the Supervisor and a service port in the Cisco WiSM.

interface Vlan192 

Description WiSM Service Port Gateway or Management Interface on CAT6K

ip address 192.168.10.1 255.255.255.0 

TKIP Countermeasure caught in the wild!

  

I want to share an event you may not see very often in the wild, TKIP countermeasure. 

What is a TKIP countermeasure and why is it important?

 

By deafult, Cisco WLCs and autonomous access points will suspend all TKIP traffic on a radio / ssid if a client sends 2 bad MICs in a 60 second period for a duration of  60 second. This is a measure that prevents the spoofing of frames by hackers.

 

Fully authorized wireless clients can occasionally send a bad MIC(s). In fact, a colleague of mine once had a bad wireless NIC that was notorious for throwing bad MICs. His machine was a walking "DoS" attack of sorts. LOL

 

The TKIP countermeasure is a configurable variable by SSID and can be disabled. I blogged about this in December of last year. The commands for both the WLC and Autonomous are below:

WLC - http://www.my80211.com/cisco-wlc-cli-commands/2009/12/29/configure-tkip-countermeasure-holdoff-timer-on-wlc.html

Autonomous - http://www.my80211.com/cisco-auton-cli-commands/2009/12/29/configure-tkip-countermeasure-holdoff-timer-on-autonomous.html

So what happen?

I was simply reviewing logs in WCS when an alert popped up. Once I seen 'MIC' in the header I thought right away, is this a TKIP countermeasure event and sure enough. I've since monitored the device to insure it wasnt a problem child.

NOTE: Cisco recommends to disabled TKIP Countermeasure on all Voice SSIDs.

 

Cisco WLC / Rogue WCS Attack “All your base are belong to us”

Geo - “I blogged on my site about the unencrypted RRM packet just a few weeks ago. The RRM packet got little attention, but I seen this as a much bigger issue. I seen this as more than just an IP address in the clear but rather a gold mine of information, but just how could it be exploited. “

In this tutorial I will share with you an attack using the recently identified and less talked about security vulnerability with the Cisco RRM packet in conjunction with SNMP. I would like to emphasize --- this video is to educate network engineers,  system administrators and security professionals of the potential risk of a enterprise wide attack on your Cisco Unified Wireless Network if Cisco best practices are not followed.

The foundation of this attack is to use the less talked about RRM and widely known SNMP vulnerabilities.  There isn’t  anything new that isn’t already known about these vulnerabilities, but what I will share  is the concept of an attack and the real world potential it may have in your enterprise especially if you use default strings or and more importantly if an attacker knows your strings on the WLC. The concept of the attack is simple, sniff the RRM packet, discovery the WLC, and then join the WLC to the rogue WCS server. After which point your wireless network is at the complete mercy of the hacker. The hacker could create a “rogue” ssid for later outside attack over wireless, complete DOS attack of your wireless network enterprise wide, delete admin accounts on the controllers to prevent you from logging into the controllers while an attack is underway.

 

There is more to the recent Cisco Wireless OTAP issue that isn’t being widely reported.

In the last week you heard about the OTAP issue. OTAP stands for Over The Air Provisioning. It is a means whereby a Cisco access point can find a Cisco controller to initiate a join process.

OTAP when enable, by design , sends the controller mac and ip information in the clear every 60 seconds in the multicast RRM packet. This aids access points to join the network.

Cisco recommends you disable OTAP during normal production. OTAP should only be deployed during the deployment phase of a wireless network.

What isn’t being reported, when disabled the RRM packets still includes the controller mac and ip address!

 Enjoy the video 

 

Update on Saturday, September 12, 2009 at 10:41AM by George

OTAP UPDATE 9.07.09:my80211.com article picked up by computerweekly.com

http://www.computerweekly.com/Articles/2009/09/07/237584/video-cisco-access-points-give-away-network-secrets.htm

OTAP UPDATE 9.12.09: This week Cisco released a plan to follow up with a patch update to 6.x, which REMOVES OTAP discovery method and encrypts the information element in the RRM discovery packet.

I like this move and something I stated from the early release of this vulnerability. The RRM packet sending controller IP information in the clear to share RRM neighbor information is not necessary for access points that have already joined a controller. This infromation should be encrypted.
.This is comforting news for ANY enterprise or healthcare security team.

I am disappointed the release will be 6.x. Many users are on harbor code 4.2.x who won’t be able to take advantage of this patch. I suspect Cisco will release a 4.2 fix as well, we shall see!

 http://tools.cisco.com/security/center/viewAlert.x?alertId=18919